This Page Is Inserted by IFW Operations 
and is not a part of the Official Record 



BEST AVAILABLE IMAGES 



Defective images within this document are accurate representations of 
the original documents submitted by the applicant. 

Defects in the images may include (but are not limited to): 



BLACK BORDERS 

TEXT CUT OFF AT TOP, BOTTOM OR SDDES 
FADED TEXT 
ILLEGIBLE TEXT 
SKEWED/SLANTED IMAGES 
COLORED PHOTOS 

BLACK OR VERY BLACK AND WHITE DARK PHOTOS 
GRAY SCALE DOCUMENTS 



IMAGES ARE BEST AVAILABLE COPY. 



As rescanning documents will not correct images, 
please do not report the images to the 
Image Problem Mailbox. 



® 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



IllilUlllllllllll 

© Publication number: 0 588 046 A1 



@ 



EUROPEAN PATENT APPLICATION 



© Application number: 93112622.1 
© Date of filing: 06.08.93 



© int. CIA G06F 13/38, G06F 9/44 



® Priority: 14.0a92 US 930584 


(jy Applicant: International Business Machines 


© Date of publication of application: 


Corporation 


Old Orchard Road 


23.03.94 Bulletin 94/12 


Armonk, N.Y. 10504(US) 


0 Designated Contracting States: 


@ Inventor: Bartek, Brice Alan 


DEFRGB 


2505 Water Well Lane 




Austin, Texas 78728(US) 




Inventor: Mclntyre, Michael Sean 




14702 Great Willow Drive 




Austin, Texas 78728(US) 




Inventor: Musta, Charles Anthony 




6629 Whitemarsh Valley Walk 




Austin, Texas 78746(US) 




© Representative: Burt, Roger James, Dr. 




IBM United Kingdom Limited 




Intellectual Property Department 




Hursley Park 




Winchester Hampshire S021 2JN (GB) 



© IEEE standard 802.2 virtual device driver. 



CD 
O 

00 
00 

in 



© In a computer network having a plurality of 
nodes with one or more computer systems asso- 
ciated with a node a method for transmitting mes- 
sages to and from a DOS application resident in a 
memory to and from the network. The messages to 
and from the DOS application are handled a virtual 
device driver resident in the memory which is moni- 
toring the 5C interrupt. The virtual device driver 
converts an outgoing CCB1 message from the DOS 
application to a message in a CCB3 32-bit format 
and an incoming 32-bit CCB3 message to a CCB1 
format. The virtual device driver transmits the CCB3 
message to a physical device driver resident in 
system memory. The physical device converts mes- 



sages between the CCB3 32-bit format and a CCB3 
16-bit format. The physical device driver transmits 
and receives 16-bit CCB3 messages to and from a 
logical link control protocol driver resident in the 
memory. The logical link control protocol driver is 
preferably written to the ISO 8802-2 standards and 
passes and receives messages to and from the MAC 
layer and the LAN adapter. With an incoming mes- 
sage the virtual device driver arms a context hook 
which fires when the operating system has allocated 
sufficient memory to the DOS application resident 
Virtual 86 mode before transmitting the CCB1 mes- 
sage to the DOS application. 
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This invention relates generally to data pro- 
cessing systems in an interconnected environment. 

It is becoming increasingly prevalent to couple 
a plurality of data processing systems in an inter- 
connected computing environment such as a Local 
Area Network (LAN) or Wide Area Network (WAN). 
Jhe networks are becoming increasingly compli- 
cated, with several different LAN networks of dif- 
ferent protocols coupled together with the data 
processing systems from multiple vendors in the 
network. 

To assure that different network technologies 
can communicate with each other, most vendors 
provide capability to interface according to the 
IEEE and International Standard Organization's 
standards for Local Area Networks. ISO 8802-2 
(IEEE Standard 802.2-1989) Logical Link Control 
Protocol describes the data link layer in a Local 
Area Network. ISO 8802-3 (IEEE Standard 802.3- 
1988) describes a bus utilizing CSMA/CD as the 
access method. ISO 8802-4 (IEEE Standard 802.4- 
1985) describes a bus utilizing token passing as 
the access method. ISO 8802-05 (IEEE Standard 
802.5-1989) describes a ring utilizing token passing 
as the access method. ISO 8802-07 describes the 
ring utilizing a slotted ring as the access method. 
This family of standards deals with the physical 
and data link layers as defined by the ISO open 
systems interconnection reference model. 

The operating system of a computer system is 
responsible for controlling the computer hardware 
components such as a graphic display, a disk 
storage device and a printer according to sets of 
instructions in the system memory and through the 
agency of a plurality of code modules called device 
drivers. If a personal computer is coupled to a local 
area network, it will typically include a LAN adapt- 
er, a piece of hardware, and a LAN device driver 
written compatibly to the ISO and IEEE standards. 
One of the first widely successful operating sys- 
tems for a personal computer system was the 
Personal Computer Disk Operating System, com- 
monly called DOS, which is used for personal 
computers having a CPU in the Intel 286, 386, 486 
lines of microprocessors. 

OS/2 2.0 is a vastly superior operating system 
to DOS, but because of the large base of installed 
DOS applications which users are unwilling to give 
up, OS/2 2.0, to be commercially viable, must 
reliably run the DOS applications. OS/2 2.0 runs 
DOS programs in a special Virtual 8086 mode of 
the Intel 386 and 486 processors. The Virtual 8086 
mode allows each DOS application to run in its own 
protected one megabyte of memory space called a 
Virtual DOS Machine (VDM). While it appears to 
the DOS application that it is running in DOS, it 
must use OS/2 resources for any I/O calls to sys- 
tem devices which must be shared among a plural- 



ity of concurrently running applications. OS/2 2.0 
has introduced the concept of an OS/2 virtual de- 
vice driver (VDD) to intercept DOS I/O calls which 
emulates the functions of a particular hardware 

5 device. The VDD passes the I/O calls to an OS/2 
physical device driver (PDD) which has actual ac- 
cess to the device. The PDD interacts with the 
device adapter and passes the results to the VDD 
which in turn passes the results to the DOS ap- 

10 plication. 

In the LAN environment, there is a problem 
with the VDD/PDD arrangement. An OS/2 VDD is a 
32-bit ring zero application that can only interact 
with an OS/2 PDD which is also a 32-bit applica- 

rs tion. Currently, the protocol drivers and device dri- 
vers which control the LAN adapters are written to 
the ISO and IEEE standards which call for a 16-bit 
protocol. 

It is desirable to be able to transmit a message 

20 from a DOS application running in the Virtual 8086 
mode of OS/2 to the local area network without 
change to the DOS application code. 

This can be accomplished by using an OS/2 
physical device driver as an intermediary between 

25 the OS/2 virtual device driver and the IEEE 802.2 
protocol driver, rather than the OS/2 physical de- 
vice driver's normal use as an interface to an actual 
hardware device. In a computer network having a 
plurality of nodes with one or more computer sys- 

30 terns associated with a node, a CCB1 message 
from a DOS application running in a computer 
system memory is transmitted to the 5C interrupt. 
The CCB1 message is captured by a virtual device 
driver running in the computer system memory 

36 which is monitoring the 5C interrupt. The virtual 
device driver converts the CCB1 message to a 
message in a CCB3 32-bit format. The virtual de- 
vice driver transmits the CCB3 message to a phys- 
ical device driver running in system memory which 

40 converts the message in the CCB3 32-bit format to 
a CCB3 16-bit format. The physical device driver 
transmits the 16-bit CCB3 message logical link 
control protocol driver running in the computer 
system memory. The logical link control protocol 

45 driver is preferably written to the ISO 8802-2 stan- 
dards and passes the message down to the MAC 
layer and the LAN adapter. 

The method for transmitting a message from 
the network to a DOS application running in the 

50 Virtual 8086 mode in a system memory is similar. 
First, after a message is received from the network 
the logical link protocol driver delivers a 16-bit 
CCB3 message the physical device driver running 
in the computer system memory. The physical 

55 device driver converts the 1 6-bit CCB3 message to 
a 32-bit CCB3 message and sends it to the virtual 
device driver running in the computer system 
memory. The virtual device driver converts the 
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CCB3 message to a CCB1 message and arms a 
context hook. The context hook is fired when the 
operating system has loaded the memory belong- 
ing to the DOS application running in Virtual 8086 
mode. When the context hook is fired, the virtual 
device driver transmits the CCB1 message to the 
DOS application. 

Thus an improved method is provided for 
transmitting of data in a data processing system 
from a local area network application written to 
operate in the real address mode of a processor to 
a local area network through a virtual device driver 
and physical device stack written for an operating 
system which uses both the real address mode 
and protected address mode of the processor. 

A preferred embodiment of the invention will 
now be described by way of example with refer- 
ence to the following drawings in which :- 

FIG. 1 depicts a typical workstation which would 
be coupled to a network environment in accor- 
dance with the present invention. 
FIG. 2 depicts a plurality of workstations in a 
network environment according to the present 
invention. 

FIG. 3 depicts the code module in the memory 
of a workstation operating according to the 
present invention. 

FIGs. 4A-4C are flow diagrams of the configura- 
tion process to prepare DOS applications to run 
within the OS/2 2.0 Virtual DOS machines in 
accordance with the present invention. 
FIG. 5 depicts the data structure for the DOS 
configuration process depicted in FIGs. 4A-4C. 
FIG. 6 is a flow diagram for the process of 
converting an IEEE 802.2 CCB1 control block to 
an IEEE 802.2 CCB3 control block. 
FIGs. 7A-7F are flow diagrams for the process 
of handling a hardware interrupt at the LAN 
adapter to a DOS application in accordance to 
the present invention. 

FIGs. 8A-8B depict the fields in the CCB1 and 
CCB3 control blocks. 

A representative hardware environment is de- 
picted in FIG. t , which illustrates a typical hardware 
configuration of a workstation in accordance with 
the subject invention having a central processing 
unit 10, such as a conventional microprocessor, 
and a number of other units interconnected via a 
system bus 12. The workstation shown in FIG. 1 
includes a Random Access Memory (RAM) 14, 
Read Only Memory (ROM) 16, an I/O adapter 18 
for connecting peripheral devices such as disk 
units 20 to the bus, a user interface adapter 22 for 
connecting a keyboard 24, a mouse 26, a speaker 
28, a microphone 32, and/or other user interface 
devices such as a touch screen device (not shown) 
to the bus, a communication adapter 34 for con- 
necting the workstation to a data processing net- 



work and a display adapter 36 for connecting the 
bus to display device 38. 

The preferred embodiment of the subject in- 
vention is an IBM Personal System/2 with the IBM 

5 OS/2 operating system installed. Detailed descrip- 
tions of the hardware and software environment are 
provided in PS/2 Hardware Interface Technical Ref- 
erence, S10G-6457, IBM Corporation (1991), and 
OS/2 Presentation Manager Programming, SC28- 

io 2700, IBM Corporation (1992). While the invention 
will be described in terms of this hardware and 
software, one skilled in the art will recognize that 
other operating systems and hardware can be sup- 
ported without undue experimentation. Also resi- 

75 dent on the computer system is the OS/2 LAN 
System Software support including the software 
making up the subject invention. The system soft- 
ware used in the previous release is described in 
the following publications available from IBM and 

20 incorporated herein by reference. IBM Operating 
System/2 Local Area Network Server Version 2.0 
Information and Planning Guide (G236-0162); IBM 
Local Area Network Server Programs (Specification 
Sheet) (G360-2753); and IBM Local Area Network 

25 Technical Reference (SC30-3383). 

Interconnected computing environments are 
becoming much more prevalent. Network environ- 
ments are becoming more varied, consisting of 
different LAN technologies, multiple vendors and 

30 multiple adapters. There is also a higher perfor- 
mance requirement and a greater need for network 
management. FIG. 2 is an illustration of a typical 
computer network environment comprising a plural- 
ity of interconnected workstations similar to that 

35 shown in FIG. 1 . 

FIG. 2 illustrates a local area network 40 which 
is preferably an IBM token ring, however, it could 
also be an Ethernet or PC net or other LAN type 
system. OS/2 requester 42 communicates via LAN 

40 40 to LAN Server server 44 for file sharing applica- 
tion server, database server, communications serv- 
er and other services. The OS/2 Requester 42, as 
might be suspected, runs on the OS/2 2.0 operat- 
ing system. The DOS Requester 46 communicates 

45 by means of Bridge 48 to LAN 40 to request 
similar services from the LAN Server server 44. 
Similarly, the DOS Requester 46 runs on the DOS 
Operating System 5.0. The Bridge 48 is used to 
couple the DOS Requester 46 and Network Server 

so 50 via Ethernet 51 to the LAN 40. The Netware 
Server 50 runs on the Novell NetwareTM local area 
network software and provides an example of the 
level of integration of vendors which is possible in 
today's local area networks. The OS/2 SNA gate- 

55 way 52 provides service to the LAN 40 via bus 54 
to the other networks which are using the SNA 
Protocol. Finally, powerful RISC based workstations 
such as the RISC System/6000 56 can also be 
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coupled to the local area network 40. 

LAN adapter and Protocol Support (LAPS) con- 
sists of the network communication software neces- 
sary to support LAN connectivity. LAPS is a com- 
bination of Network Driver Interface Specification 
(NDIS) compliant protocol drivers, NDIS compliant 
network adapter drivers, Application Program Inter- 
face (API) support software, and configuration and 
installation software for the drivers. The IBM Net- 
work Basic Input/Output (NETBEUI) has been ex- 
tended to interface to NDIS and to the 802.2 speci- 
fication. A complete description of the 802.2 com- 
munication standard is available in International 
Standard (ISO) 8022 (1989). FIG. 3 is a block 
diagram of the LAN Adapter and Protocol Support 
for OS/2 2.0. 

The CPU within a computer can process in- 
formation relatively quickly. However, the computer 
input and output devices are slow. Each of these 
devices is controlled by a device driver which 
isolates the rest of the software from the I/O de- 
vices. Each device driver is programmed with the 
physical characteristics of the device. 

In the Personal Computer Disk Operating Sys- 
tem (PC/DOS) each PC adapter in the personal 
computer uses a certain interrupt in the interrupt 
vector table and in the case of a local area network 
adapter card Talking IEEE 802.2 or NETBIOS it is 
interrupt 5C (Int 5C). The LAN adapter card can be 
a Token Ring adapter card, it can be PC Net 
adapter card, it can be an Ethernet adapter card, 
etc. The Interrupt 5C is used by software applica- 
tions to interface with the LAN device driver which 
interfaces to the LAN adapter card. When an ap- 
plication wants to give data to the LAN adapter 
card to transmit out on the LAN, interrupt 5C is 
invoked. The application uses a command control 
block (CCB), for example, a CCB transmit, and 
within the control block there are one or more 
pointers to data. If an application wants to send the 
string "1, 2, 3, 4 and 5", it supplies a pointer in the 
CMD control block to a data string and invokes 
interrupt 5C. The computer system gives the data 
to the LAN adapter card to transmit out on the 
LAN. Conversely, when data arrives at the PC from 
the LAN via the LAN adapter card, the LAN device 
driver looks at the frame, determines the type of 
frame and gives the data to the application via 
interrupt 5C. The system refers to the DOS inter- 
rupt vector table, gets the address of the device 
driver which handles the interrupt, makes a control 
block and transfers control to the device driver's 
address so that the data can be decoded and 
processed. 

In one example of the prior art in a pure DOS 
environment the interrupt 5C handling for the LAN 
adapter was done by an IBM product called LAN 
Support Program interfaced to the LAN adapter, 



passed control blocks to the LAN adapter contain- 
ing data to be transmitted on the LAN and con- 
trolled transmission of the data to remote destina- 
tion. Data sent out on the LAN and coming in off 

5 the LAN is passed via interrupt 5C to LAN support 
program which would then in turn give it to the 
application. The LAN support program can work in 
an OS/2 2.0 environment, however, since it was 
coded assuming that it had exclusive use of the 

10 LAN adapter there are no provisions made for 
sharing the LAN adapter. In other words, no other 
protocol stack can use the LAN adapter once LAN 
support program has initialized. 

Under OS/2 2.0 virtual device drivers service 

rs DOS interrupt requests. This allows a DOS applica- 
tion to run unmodified within OS/2 2.0. There are 
two different operating modes on which a DOS 
application may run, Virtual 8086 mode (V86 mode) 
and a VM Boot mode. When a DOS application 

20 runs Virtual 8086 mode a VDD may allocate normal 
DOS memory. However, when a DOS application 
runs in a VM Boot mode, the allocation of normal 
DOS memory is not allowed by the OS/2 2.0 op- 
erating system. Therefore, an alternate mechanism 

25 to get the necessary memory allocated for the VDD 
is needed so that the DOS applications interrupt 
request can be satisfied. 

One preferred method is to include a simple 
DOS device driver, whose purpose is to allocate 

30 DOS memory for use by the VDD. When the DOS 
driver initializes it has knowledge of how much 
memory the VDD needs, this value is the maximum 
amount of memory that the VDD would need to 
access in the VM Boot environment. As the DOS 

35 driver initializes, it places in its data area address 
into a command control block (CCB) which it is- 
sues to the interrupt 5C which the VDD has taken 
control. The command code that the DOS device 
driver places into the CCB is one which signifies to 

40 the VDD that the address following is the address 
of the DOS driver's data area and that its memory 
is for use by the VDD. Upon receipt of the CCB, 
the VDD then initializes the memory by inserting its 
control block signatures. 

45 FIG. 3 depicts a plurality of software modules 

which would be resident in the random access 
memory of a workstation operating in accordance 
with the present invention. As part of the OS/2 2.0 
Operating System 100, there is a MVDM manager 

so 102 that manages the multiple virtual DOS ma- 
chines that run under OS/2 2.0 in the V86 mode. 
The V86 mode is the emulated DOS mode that 
OS/2 provides for DOS applications to enable them 
to run unmodified. Those DOS applications which 

55 are accustomed to LAN communications can re- 
main unmodified and as previously described 
would invoke interrupt 5C, that interrupt 5C vector 
now contains the address of a virtual device driver 
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130. When the virtual device driver 130 gets a 
command control block from one of the applica- 
tions via the MVDM manager 102, it passes the 
control block to the 802.2 PDD 132. The 802.2 
PDD 132 is a 16-bit OS/2 physical device driver 16 
running in the OS/2 protect mode. The PDD 132 in 
turn passes the control block to the 802.2 protocol 
driver 134 and the 802.2 protocol stack then ser- 
vices that request, either by transmitting or receiv- 
ing data across the NDIS interface 136. The ap- 
plications 110 running in OS/2 protect mode also 
can share the LAN adapter now that the virtual 
device driver 130 and physical device driver 132 
have enabled the DOS applications to share the 
adapter. The OS/2 protect mode applications 110 
use the 16 and 32 bit API's 112 to issue control 
blocks. The control blocks are passed directly to 
the 802.2 protocol drivers 134 which in turn ser- 
vices the API control block request and either 
transmits or receives data over the network. The 
LAN technical reference which describes the 802.2 
protocol, details the specifics of each command 
control block that can be issued to the 802.2 pro- 
tocol stack. 

In FIG. 4A, step 150 is the start of the DOS 
configuration utility. One preferred embodiment of 
the DOS configuration utility is a DOS program that 
is invoked from a DOS command prompt or is part 
of a .BAT File in DOS. In step 152 a call is made 
for the initialization of the data structures that will 
be used in the DOS configuration program and 
passed to the virtual device driver. The main data 
structure is the configuration control block which 
consists of four fields. The first field being at offset 
0 in the control block is the command code which 
is predefined to be "0XFA". The second part of the 
control block at offset 1 is defined to be the error 
code indicating to the virtual device driver whether 
or not an error in input had occurred. The third 
byte of control block at offset 2 is the 
"SEND.NO.ACK flag" which indicates to the virtual 
device driver whether the SEND.NO.ACK support is 
being requested from the DOS application. The 
fourth byte of the structure at offset 3 is a byte 
filler so that the virtual device driver remains on an 
even word boundary. 

Next, embedded in the control block is a 5X16 
array, using five distinct resource request variables 
and the 16 LAN adapters to support as indexes. 
The memory for this control block is initialized also 
in step 152 to the area of memory allocated by the 
DOS configuration program. Additionally, the adapt- 
er number variable which indexes from 0 through 
15 for each adapter number is initialized to begin at 
adapter 0. The first check that is made in the DOS 
configuration program is for the number of input 
parameters, in step 154. rf the number of input 
parameters is 0, no input has been provided to the 



configuration utility and all default values will be 
used. If input is provided to the DOS configuration 
utility, step 156, a loop is constructed to process 
each input parameter individually. Each input pa- 

5 rameter is checked to see if it is 0, step 158, 
meaning that it is the last configuration parameter 
processed and there are no further parameters to 
be processed. 

If there are no further parameters, the process 

10 continues to the issuance of the configuration con- 
trol block to the interrupt 5C interface. In the next 
check in step 160, the input is checked across a 
switch construct with cases for each of the variable 
resource values, "S" for Sessions, "C" for Com- 

75 mands, W D W for Direct station support, "N" for 
Names and "A" for SEND.NO.ACK Support. In 
each case, the switch statement constructs a spe- 
cific request variable assigning to that the amount 
of that resource as requested. Each resource vari- 

20 able is checked against, an allowable range for that 
parameter, hf the requested value is outside the 
allowable range, a flag is set indicating that there 
has been invalid input into the configuration utility. 
Since there was invalid input, ail the request vari- 

25 ables will be set to their default value. 

As part of the case statement constructed in 
step 1 70, there are two special identifiers provided: 
the first is a back slash as in step 170 that tells the 
DOS configuration facility to index to the next 

30 adapter value or column in the 5X16 configuration 
matrix as depicted in FIG. 5. The second identifier 
is an equal sign that as in step 174 which tells the 
DOS configuration utility program to copy the re- 
quested variables from the current adapter to the 

35 next adapter. If the input parameter does not sat- 
isfy the tests in step 160, 170 or 174, it falls 
through to step 178. Once the invalid argument flag 
is set to TRUE 1 , a comparison is made to that flag 
in step 180. rf the flag is set to true all defaults will 

40 be taken in the 5X16 matrix as shown in FIG. 5. In 
step 184, a check is made to see if name number 
one support is requested and the names are equal 
to the default; if so, one name is added to the 
amount requested. As name number 1 is itself a 

45 name, the user has 17 available names, instead of 
16. The process continues in step 188 where the 
actual configuration control block is issued to the 
interrupt 5C handler. 

FIG. 6 is a flow diagram of the procedure 

so which captures a CCB1 control block issued from a 
DOS application, passes it to the 802.2 virtual 
device driver passing it to the physical device 
driver and further passing it onto the 802.2 protocol 
driver. The process starts at step 200 where an 

55 interrupt 5C is received from the DOS application. 
This means that a CCB1 was issued by the DOS 
application to the interrupt 5C which is being han- 
dled by the VDD 802.2 device driver. In step 202, 
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the V86 mode control block address is converted 
into a linear mode control block address. The linear 
mode control block address is used by the VDD as 
it is much easier to manipulate than a V86 mode 
control block. A test is performed to determine 
whether the control block is a valid CCB1 control 
block in step 204. If not, the control block is routed 
to the error handler in step 206. The error handler 
will return an error code to the DOS application 
indicating that the control block sent was not a 
CCB1 control block. If the control block is a CCB1 
control block, in step 208, an initial copy of the 
CCB1 block is made to the trace buffer. 

In step 210, the CCB1 command code is taken 
from the CCB1 and used as an index into a table of 
local processing command specific routines, Con- 
trol is transferred to a specific routine based on the 
CCB1 command code. In step 212 through 218, 
there are four representative commands that are of 
particular interest to the VDD. There are many 
other command specific routines which may be 
addressed in translating a CCB1 control block to a 
CCB3 control block that will ultimately be sent to 
the OS/2 802.2 protocol stack. In step 212, direct 
open adapter issuing a CCB1 
DIR.OPEN.ADAPTER. Three functions that the vir- 
tual device driver may need to perform on behalf of 
the DOS application include setting a group ad- 
dress, setting a functional address and opening the 
direct station on behalf of the DOS application, if 
configured. In step 214, the command chosen is 
DLC open service access point (SAP) where the 
virtual device driver will create its own SAP buffer 
pool. One of the key design points of the DLC 
open SAP is that there are two buffer pools that are 
managed by the virtual device driver. One buffer 
pool is the DOS CCB1 buffer pool and the second 
one is the CCB3 OS/2 SAP buffer pool that the 
virtual device driver will use when communicating 
to the OS/2 802.2 protocol driver. 

When a transmit CCB1 is issued to the virtual 
device driver by the DOS application in step 216, 
the virtual device driver will copy the data to be 
transmitted into one of its own buffers in order to 
send that buffer to the 802.2 protocol stack. In step 
218, the receive processing allows that when a 
receive command is issued by a DOS application, 
the virtual device driver will put a receive command 
to 802.2 OS/2 protocol using buffers that the virtual 
device driver had constructed during the DLC open 
SAP processing. 

In step 220, CCB3s are issued asynchronously 
to the OS/2 802.2 protocol driver. In step 222, 
CCB3s are issued asynchronously to the 802.2 
OS/2 protocol stack. The CCB3s that come from 
steps 220 and 222 are processed in step 224, 
where the LAN PDD module a 16-bit physical de- 
vice driver issues them to the 802.2 protocol driver 



in step 226. The call return model between the 
VDD and the LAN PDD 224, is a 32-bit call return 
model. The call return model between LAN PDD 
and 802.2 protocol driver is a 16-bit call return 

5 model. The LAN PDD is provides a 32-bit to 16-bit 
compatibility call return model module. 

FIGs. 7A-7F are flow diagrams of the asyn- 
chronous completion processing on a hardware in- 
terrupt from a local area network communicating 

w back to the DOS application. After the hardware 
interrupt has passed up through the network adapt- 
er and the NDIS layer to the 802.2 protocol driver, 
the 802.2 protocol driver in step 250 needs to 
notify the virtual device driver of completion of a 

rs hardware interrupt, ft does so through the LAN 
PDD. A LAN DD 16-bit control block is passed by 
the 802.2 protocol driver to the 802.2 PDD in step 
250. 

In step 252, the LAN 802.2 PDD will receive 

20 one of three events from the 802.2 protocol driver: 
a CCB3 completion, a received data completion; or, 
an exception event completion. In step 254, the 
type field in the CCB3 is set according to the type 
of event. This event is passed by the PDD where 

25 the event is put on a completion queue 256 to be 
retrieved at a later time. Then a check is made, in 
step 258, to see if the DOS context hook is already 
armed, which is to be fired at a later time. The 
DOS context hook is used to determine whether 

30 the specific VDM which will ultimately receive the 
message is loaded and active in the foreground. If 
the context hook is armed, control goes back to the 
operating system to wait for the context hook to 
fire, in step 259. If the context hook is not armed, 

35 the context hook is then armed in step 260 and 
then control is given back to the operating system 
in step 259. 

In the second portion of FIG. 7A, the DOS 
context hook fires that was armed in step 260 

40 indicating that the DOS context is in place. Control 
is given to the VDD from the MVDM manager in 
step 262, the VDD control is in CCB context in step 
264 and then, in turn, to CCB APPEND in step 266. 
CCB context is the procedure which gets control 

45 after the DOS context hook fires. CCB APPEND is 
the procedure which processes the completion 
queue. The event that was placed on the comple- 
tion queue in step 256 is taken off the queue in 
step 266 and then examined to determine which of 

50 the three events, in the tests in steps 268, 270 or 
272, the element pertains. If the test is positive in 
step 268, the event taken off the completion queue 
is a CCB3 completion. The event will proceed to 
step 274 where the CCB3 will have an associated 

55 CCB1 to be completed back to the DOS applica- 
tion. When the CCB1 is sent to the LAN and 
translated to a CCB3, the segment offset and linear 
addresses of the CCB1 and CCB3 are kept in a 
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cross-reference field at the end of the CCB3. This 
information is used when the CCB3 is completed 
back by the message on the LAN. STI hook is a 
way for a VDD to get information to a DOS applica- 
tion without interrupting an important part of the 
DOS application process. If the test in step 278 
determines that the application CCB1 has a post 
routine defined, an STI hook will be armed in step 
280 to call the DOS application when interrupts are 
enabled in the DOS context. W the CCB1 does not 
have a post routine, control will be returned to step 
274 in a loop processing CCBs until all CCBs are 
exhausted. The type of event received by the PDD 
determines which test 268, 270 is performed. If it is 
a receive, step 276 forwards the data to step 316 in 
FIG. 7D. If it is an exception, step 272 forwards the 
data to step 334 in FIG. 7E. 

FIG. 7B is a flow diagram which outlines the 
802.2 asynchronous completion processing on a 
CCB STI hook firing. Control is given to the 802.2 
virtual device driver as the result of a STI hook 
firing (meaning that interrupts are enabled in a 
DOS context), a check in step 282 is made to 
ensure that the operating system is in protect 
mode. If the operating system is not in protect 
mode, the check in step 282 will trigger step 284 
which switches to V86 mode. 

The process continues on to step 286 where 
the client register frame (CRF) is saved. Also, in 
step 286, the DOS flags are saved on the stack 
that the DOS application is using; the flags are kept 
in one of the registers of the CRF. The CRF is a 
structure that contains the values for all the regis- 
ters in a specific DOS contest. DOS interrupts are 
disabled and the CCB1 is returned. A check is 
made, in step 288, to see if the command complet- 
ing is a receive. The virtual device driver has to 
treat the receive completion differently than other 
command completions due to the nature of the 
receive command. The receive stays outstanding 
forever, so the receive command given to the 802.2 
OS/2 protocol driver is not cancelled. If the receive 
data appendage test is true in step 288, the virtual 
device driver will call the DOS appendage in step 
290, arm a return hook that will give control back to 
the virtual device driver when the DOS application 
program does an interrupt return. Also, in step 290, 
the virtual device driver will arm a timer that will 
give control back to the virtual device driver after a 
predetermined period in the event that the DOS 
application program never executes an interrupt 
return. If the command completed to the virtual 
device driver is not a receive data appendage in 
step 288, the virtual device driver will call the 
CCB1 completion routine in step 292. Further, in 
step 192, the VDD will issue a return hook, free the 
CCB3 control block issued to the OS/2 802.2 pro- 
tocol driver and set a timer that will give control 



back to the virtual device driver after a predeter- 
mined period in the event that the DOS application 
program does not perform an interrupt return. Con- 
trol is then given back to the OS/2 2.0 operating 

5 system in step 294, while the process waits for the 
return hook that was armed in step 292 to fire. 

The flow diagram in FIG. 7C depicts the pro- 
cess of CCB return hook processing. Control is 
given to the virtual device driver, after a CCB return 

w hook fires, by the MVDM manager in step 300. 
After a specified period of time, a check is made, 
step 302, to determine if the dead man timer is still 
armed. If the timer is armed, the timer is disarmed 
in step 304. A check is performed in step 306 to 

75 see if the timer had fired inappropriately. If the 
timer had fired inappropriately, control is given 
back to the operating system. H the timer is 
deemed to have fired correctly, the process pro- 
ceeds to step 308 where the client register frame 

20 that contains the registers of the DOS context are 
restored to their original values. Interrupts in the 
DOS environment are enabled in step 310, and 
then in step 31 2, a check is made to determine the 
initial mode of operation, protect mode or Virtual 

25 8086. If protect mode was the initial mode of op- 
eration, a switch is made to protect mode in step 
314 and then control is given back to the operating 
system via a call to CCB APPEND. 

In FIG. 7D, 802.2 asynchronous completion 

30 processing for a receive data appendage is de- 
picted. If when the VDD is entered as the result of 
a CCB context hook firing, the event indicates 
received data, a check is made to see if the DOS 
application program has SAP buffers available to 

35 hold the arriving data, in step 316. SAP buffers 
memory that is given the 802.2 API by the DOS 
application to store data received by the LAN 
adapter for that application. If the DOS application 
does not have SAP buffers available, a test is 

40 performed to determine whether the frame coming 
in is an information frame in step 318. If so, the 
virtual device driver will emulate local busy to the 
DOS application in step 320. Local busy is a state 
in the 802.2 protocol to prevent more information 

45 being sent to a node than can be stored at the 
node. If the frame received is not an information 
frame, the OS/2 SAP buffers containing the data 
received from the network are freed, in step 322, 
and a call is made to CCB APPEND. 

50 If the DOS application does have enough DOS 

SAP buffers to hold the data, the DOS SAP buffers 
that are managed by the virtual device driver are 
reserved to contain the data received in the OS/2 
SAP buffers in step 324. The data is copied into 

55 the DOS SAP buffers from the OS/2 SAP buffers in 
step 326. A loop is performed copying all data from 
OS/2 SAP buffers to DOS SAP buffers until the 
number of DOS SAP buffers is exhausted or the 
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end of the data contained in the OS/2 SAP buffers 
has been reached, step 328. Once the data is 
copied into the DOS SAP buffers, the OS/2 SAP 
buffers are freed back to the OS/2 SAP buffer pool 
in step 330. The process continues to arm the CCB 
STI hook, step 332, that will allow the VDD to 
deliver the DOS SAP buffers back to the DOS 
application. 

In FIG. 7E, 802.2 asynchronous completion 
processing for an exception event is depicted by 
means of a flow diagram. When the MVDM man- 
ager calls the virtual device driver due to a context 
hook firing and the event hype indicated is an 
exception event, the exception event may be one 
of four types: DLC status; adapter check; PC error; 
or, system action. The type of event is found in 
step 334 by comparing the type code with the four 
different types of exception events. A check is then 
made in step 336 to see if the DOS application has 
requested to be notified on that particular type of 
status event. If not, in step 338, the element con- 
taining the data is put back on the status event free 
queue in the VDD and a call is made to CCB 
APPEND. If the DOS application program has re- 
quested notification of these events, step 340, a 
specific routine for each corresponding exception 
type is called. Exception routines DLC status in 
step 312, adapter check in step 344, PC error in 
step 346 and for system action in step 348 are 
available. In each of these four routines, specific 
status information is obtained from the element that 
was passed to the virtual device driver from the 
802.2 protocol driver. Once the appropriate excep- 
tion routine is finished and specific event process- 
ing completed, an STI hook is then armed, in step 
350, to prevent the VDD from entering the DOS 
application inappropriately, waiting until the STI 
hook is fired to complete the event back to the 
DOS application program. Control is then returned 
to the OS/2 operating system in step 351. 

The process continues with 802.2 asynchro- 
nous command processing for a CCB exception 
STI hook as depicted in FIG. 7F. A check is made 
in step 352 to ensure that the operating system is 
currently in V86 mode. If the operating system is 
not V86 mode, a switch to V86 mode, step 354, is 
made. Once it is determined that the operating 
system is V86 mode, step 356, the client register 
frame is saved. Also in step 356, the flags are also 
saved on stack, DOS interrupts are disabled and 
the client register frame is set up for the call to the 
DOS application program. A check is then made, in 
step 358, to determine whether traces are request- 
ed. If traces are requested, step 360, the event is 
traced to the OS/2 trace buffer. The process con- 
tinues to step 362 where the DOS appendage is 
called, a return hook is armed to return control to 
the virtual device driver when the DOS application 



program executes an interrupt return. Also, in step 
362, the OS/2 event element that was used to 
contain the exception event information is freed 
back to the status event free queue to be reused. A 

5 check is then made in step 364 to determine 
whether or not a CCB time out timer should be 
armed. If so, the timer is armed in step 366 and 
control is returned to the operating system in step 
367. If not, control goes back to the operating 

10 system in step 367 without arming a timer. 

FIGs. 8A-8B portray the CCB1 and CCB3 con- 
trol blocks which are described in detail in the IBM 
Local Area Network Technical Reference (SC30- 
3383). The CCB1 control block is the command 

75 control block for the IEEE 802.2 adapter support 
software, which was provided with the original To- 
ken-Ring PC adapter or rather, the Local Area 
Support Program, both products of the IBM Cor- 
poration. The CCB3 is the command control block 

20 with a device interface provided with the commu- 
nications manager of OS/2 Extended Edition 1.1 
and higher. The CCB1 and CCB3 command control 
blocks are illustrated in FIGs. 8A and 8B, respec- 
tively. In the specification, it is possible to discuss 

25 a command that might be used by both a CCB1 
and a CCB3 interface, it is done by using the term 
CCB only. 

To issue a request to a LAN device driver for 
the DOS operating system, a DOS network applica- 

30 tion program assembles a control block containing 
a command and related information for the LAN 
adapter. The application then puts the computer 
systems main memory address of this control 
block into the extra segment (ES) and base (BX) 

35 registers. At this point the DOS application invokes 
interrupt 5C. The LAN adapter device drivers re- 
spond to the 5C interrupt by processing the control 
block. 

Referring to FIG. 8A, the LAN adapter support 

40 for a CCB1 for DOS is described. The content of 
the first field indicates to the LAN device drivers 
which type of interface the DOS program wishes to 
use. If the first field contains either a "00" or "01 M 
code, the block is considered to be a CCB and 

45 either the direct interface with the DLC interface is 
being used. If the first field contains a byte greater 
than "0F n the net BIOS interface is being used, 
and the control block is to' be considered NCB 
rather than a CCB. The second field indicates the 

so CCB command perform. The third field is a com- 
pletion code as provided by the LAN adapter de- 
vice drivers. Field is set to "FF" when the CCB is 
received, while the field is "FF" the application 
must not alter CCB or any associated data. When 

55 the LAN adapter completes the command, the LAN 
device driver set the field to the appropriate com- 
pletion code, such as "00" means successful com- 
pletion. The fourth field defines a work area field 
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for the LAN adapter device drivers to use. The fifth 
field is used the application program to find the 
next command in the queue of outstanding com- 
mands or a queue of commands. The sixth field 
CCB_CMB CMPL is the address of the user AP- 
PENDAGE that the LAN adapter device drivers will 
go to upon command completion. When the AP- 
PENDAGE receives control at this point the ad- 
dress of the CCB that was completed will be in 

registers ES and BX and the CCB RETCODE will 

be in register AL. The seventh field 

CCP PARM__TAB points to additional commands 

specific parameters. 

To request a device driver interface by CCB3, 
the application program device driver must place 
the address of the CCB3 to be executed by the 
device driver interface into registers ES and BX 
and push an indication code of "0000" onto the 
OS/2 stack. The application program device driver 
then issues a far call instruction to the OS/2 Ex- 
tended Edition device driver interface intercommu- 
nication entry point. At the return from the device 
driver interface all registers will contain their origi- 
nal values, with the exception of the AX register, 
which will contain the immediate return code. 
When a given application program device driver 
makes a request to the device driver interface its 
sets the BX register to the address offset of the 
CCB3 to be executed, the ES register to the ad- 
dress selector of the CCB3 to be executed and 
pushes an indication code as 0 on to the stack. 

Referring to FIG. 8B, the first four fields in the 
CCB3 command control block are similar to those 
for a CCB1 command control block. The fifth field, 

CCB POINTER, is used by the queue pointer and 

LAN adapter device drivers. The sixth field is used 
to store the offset of the user APPENDAGE for a 
given application programs device driver. The sev- 
enth field CCB__PARM_OFFSET points to addi- 
tional parameter commands specific parameters. 
The eighth field contains another 2-bytes of param- 
eter data. The CCB__RESOURCE_ID field is used 
when more than one OS/2 application is running 
and used to clear the resources associated with an 
application when it terminates. The 
CCB_APPL_ID field contains the ID of the ap- 
plication program which issued the CCB3 com- 
mand. The CCB_APPL_KEY field contains a key 
code to provide resource security for application 

programs. The last field, the CCB Parameter2 

contains two bytes of parameter data which is 
usually the system key parameter. 

Service access points (SAP) provided means 
of communication with devices connected to the 
network. A given application program open several 
SAPs for an adapter and each SAP can have 
several link stations opened. 



Claims 

1. In a computer network having a plurality of 
nodes with one or more computer systems 

5 associated with a node, a method for transmit- 

ting a message from a process resident in a 
memory to the network, comprising the steps 
of: 

capturing a message in a first format by 
/o means of a virtual device driver resident in the 

memory; 

converting the message in the first format 
to a second format; 

transmitting the message in a second for- 
75 mat to a physical device driver resident in 

system memory which converts the message 
in the second format to a third format; and, 

transmitting the message in the third for- 
mat to a logical link control protocol driver 
20 resident in the memory to be transmitted to 

the network. 

2. In a computer network having a plurality of 
nodes with one or more computer systems 

25 associated with a node, a method for transmit- 

ting a message from the network to a process 
resident in a system memory, comprising the 
steps of: 

transmitting a message in a third format 
30 from a logical link protocol driver resident in 

the memory to a physical device driver resi- 
dent in the memory; 

converting the message in the third format 
to a second format; 
35 transmitting the message in the second 

format to a virtual device driver resident in the 
memory; 

converting the message in the second for- 
mat to a first format; and, 
40 in response to the determination that the 

process has sufficient memory allocated, trans- 
mitting the message in the first format to the 
process. 

45 3. The method as described in claim 1 or 2 
wherein the virtual device driver controls a first 
and a second buffer within the memory, the 
first buffer contains messages in the first for- 
mat and the second buffer contains messages 

so in the second format. 

4. A computer system attachable to a computer 
network having a plurality of nodes with one or 
more computer systems associated with a 
55 node, the computer system including means 

for transmitting a message from a process 
resident in a memory to the network compris- 
ing: 
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a virtual device driver means for capturing 
a message in a first format, the virtual device 
driver resident in the memory; 

means for converting the message in the 
first format to a second format; 5 

means for transmitting the message in a 
second format; 

a physical device driver means resident in 
the system memory for receiving the message 
in the second format and for converting the 10 
message in the second format to a third for- 
mat; and, 

means for transmitting the message in the 
third format to a logical link control protocol 
driver resident in the memory to be transmitted rs 
to the network. 

5. A computer system attachable to a computer 
network having a plurality of nodes with one or 
more computer systems associated with a 20 
node, the computer system including means 

for transmitting a message from the network to 
a process resident in a memory comprising: 

means for transmitting a message in a 
third format from a logical link protocol driver 25 
resident in the memory; 

a physical device driver resident in the 
memory for converting the message in the 
third format to a second format; 

means for transmitting the message in the 30 
second format; 

a virtual device driver resident in the mem- 
ory for converting the message in the second 
format to a first format; and, 

means responsive to the determination 35 
that the process has sufficient memory allo- 
cated, transmitting the message in the first 
format to the process. 

6. The system as claimed in claim 4 or 5 wherein ao 
the virtual device driver controls a first and a 
second buffer within the memory, the first buff- 
er contains messages in the first format and 

the second buffer contains messages in the 
second format. 45 
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